Night Owl - The Best of BBS

home *** CD-ROM | disk | FTP | other *** search

/ Night Owl - The Best of BBS / Night Owl The Best of BBS (NOP-BBS) (Night Owl Publisher) (1994).iso / 022a / jm940310.lha / jammail.doc < prev next >

Wrap

Text File | 1994-03-09 | 36KB | 772 lines

March 8, 1994 I'd like to remind everyone that what is in this documentation file is still valid, even though its not been changed in a while. I have received a number of support questions in Email on topics that are fully covered in this manual. Please note that I have also begun the steps to starting up a new support conference. I now have it listed in the International FidoNet Echolist. From this point, i'm going to try to get it on the Zone1 Backbone (starting on the Region12 backbone). I'm also going to try to get the list gated into an Internet mailing list so internet people can get support as well. So you fidonet people, especially those in Canada, and in Region12, send messages to your NEC so we can get this area on the backbone. January 29th, 1994 *****NOTE**** This documentation file has not changed much relating to the new features/fixes that I have added in the last month. Most of the changes are documented in the Readme (Changelog) file. There is a very good reason for this file to not have been updated: I am writing a completely new version of JamMail, complete with a full GUI, and full input/correction routines. Because I figure it will take me a little bit of time before I get a version of JamMail out with a GUI, I thought I should send this version out, as it has bug fixes and such that people reported from the .98.25 version (1210 or 1216 archives). Stay tuned for a brand new version! I will likely have a small preview of the new gui in this archive. Tell me what you think! Some Major Changes are: (ie, this manual is wrong in these areas :-) The S:Setup script is now generated, and all window options are configurable inside of the JamMail Window/Log menu. ***EMSI*** Yes, this update release of JamMail should support full inbound and outbound EMSI! There are problems receiving calls from Portal of Power mailers, but I have been attempting to get in contact with the author to find a solution (he doesn't send any of the "hello, I support EMSI" messages when dialing out, he just spews out his "Hello, this is who I am" packet, which either causes about a 20 second timeout delay on inbound sessions, or causes a failed session. UUCP2 call type now supported. This will allow you to have two different UUCICO options (as well as a second UUCICO binary if you wish), so you can support the larger block sizes for other systems that support it, and still support the small packets for those dumb systems on the other end. Please send me a message if you find any problems with this version, and have any suggestions for the new GUI version of JamMail. James McOrmond -------------------------------------------------------------------------- January 5, 1994 JamMail 0.98.25 Documentation By James McOrmond Fidonet#1:163/139.0 ZyXELNET#18:18/0.0 AmigaNet#40:553/139.0 ab207@freenet.carleton.ca Data: (613)521-0455 19.2k Data: (613)521-5680 28.8k Note: This documentation is not complete. If you have a specific question about setting something up, please do not hesitate to contact me. I do not have a lot of spare time right now, so will be updating the manual as people ask questions. Table of Contents ================= 1. Some questions about JamMail, what it does, and its history. 2. Installing JamMail. 3. Instructions on the use of the Menu system. a. Setting up Fidonet. b. Setting up UUCP. c. Setting up Atomic Clock configs. d. Setting up the Other call types. e. Phone line/modem configs. f. Login Menu options g. Bulletin Board Launching configs. h. Server text files. i. Using XferqSH or other File request servers. j. Logs & Windows options. k. Configuring the internal Scheduler. l. Using the Long distance Calling options. m. Use of JTPhone for setting up a phone book. 4. What's necessary for a Point/End User to configure? 5. What's necessary for a full Node to configure. 6. Using a Cron with JamMail. 7. Distribution. 1. What is JamMail? JamMail is the first WPL.library mailer genertor. What this means is through the use of the JamMail program, you will be generating a custom Front end for your system. No extra code will be in the .wpl file that isn't required for your system. If you are running as an end user and don't answer the phone at all, not a line of code that is for answering the phone will be created. Once you have generated your S:JamMail.Wpl file, you will not need to run the JamMail program again unless you need to change something. The S:Setup script launches WPL and loads and runs the S:JamMail.wpl script that you generated. What features can a WPL program written by JamMail have? JamMail was primarily written to make it easier for me to add things to my system, so the first thing the JamMail binary was required to do, was to be able to generate a program that had the same features as the file I had written by hand. Some of these features were: Fidonet support, UUCP support (launching UUCICO on inbound and outbound calls), Atomic clock setting (it dials up an atomic clock system, and accuratly sets your system clock). It also had to be able to easily launch whatever BBS software I happened to be running at the time. A simple scheduler was also required, so I put one in. The BBS program I've been running during most of the time i've been writing the JamMail binary, is VBBS. VBBS is a multi-tasking Graphical User interface BBS system. A requirement of using VBBS, was that you had to be using the VBBS terminal program, so I made it possible for users to download files right from my JamMail/Login prompt. At this point, I also set things up so people could do standard Fidonet File requests right from the login prompt, and they can be connected to my system with their favourite Terminal program (that supports Batch Zmodem transfers). Now that JamMail was able to generate and easily configure all of these options, I started into the "new" options that are only available through the generator. I started by making the system Multi-line capable with one script. Currently, i've limited the number of lines to 9. This is purely a cosmetic limitation. If someone requires a frontend on more than 9 lines, they can contact me, and i'll compile a version for them. Now that JamMail is multi-line, a much improved Scheduler was required, so I enhanced the scheduler significantly. I also wanted a way to specify which lines were used to dial specific sites based on what type of modem they had, what their address was or simply on their phone number. Now that there is a nice window there showing what the scheduler is doing, I figured it would be good for the user to be able to use that window for something, so i've set it up, that you can press CTRL-C in that window, and have the scheduler close down. You can also configure the scheduler to close all of the JamMail lines when it exists as well. Pressing CTRL-D in the Scheduler window, causes the scheduler to start its WaitLoop over again, and pressing CTRL-F in the window causes the scheduler to timeout whatever it is currently doing (Unless it is in the middle of making a call). On or about this time, I picked up a Unitel account. Unitel is an "alternative" long distance phone company. Fax routers are available, which is a little black box they'll stick between your Fax/Modem and the phone line, but I figured i'd not get one of those and simply build the feature into JamMail. If the phone number your dialing matches a pattern (the default is "(1-|011-)#?") it will pre-pend a dialing code onto any phone number correctly configured as Long distance from a North American site. I also wanted to be able to list all of the LD calls I made with JamMail, so any number that matches the above pattern will be sent to a special LogProc message port to be logged in a seperate file as well. (see section on Logproc for more information on the logging functions of JamMail). Because I own a ZyXEL modem, some ZyXEL features are supported. The system can be programed to support CallerID in a couple different ways. The first thing it does is log the CallerID messages in your main log, so you can always see where that caller had been calling from. It also puts this CallerID string in an ENV: variable called $(line).CID so your BBS program can make use of it, if it can. Also I personally find it a bit annoying if someone blocks the CallerID from showing where they are calling from, so JamMail has a few options here. The first thing it can do, is display a text file right before the main prompt saying that it has identified that they have blocked the CallerID. Also, you can configure the system to not allow them to log into one of your Bulletin boards, and if you wish, it will hangup as soon as it displays the warning text file. The same options exist for the User file requesting functions. JamMail has the option to launch Fax software, but since I do not have any, this function has not fully been tested. Also, if some usefull VoiceMail software becomes available, I will support it if possible. VoiceMail will likely be supported by using the distinctive ring feature of the modem. I do not trust the concept of attempting a Voice session when you also support Data on the same line, but distinctive ring will allow you to know what type of call it is before you answer the phone. The other option, is to support VoiceMail on a line that you don't receive Data calls (ie, an end user, just running the system as an answering machine, that you can call out from). 2. Installing JamMail. The files in the libs/ directory from this archive should all be moved to your libs: directory. The files in the s/ directory, should be moved to your s: directory. The files in the bin/ directory should be placed somewhere on your path: There are two versions of JamTool included in the archive. JamTool_T uses the Traplist.library to access a nodelist, and JamTool_I uses Nodelist.library to access a nodelist (Igen style currently exists). You should select which format you will be using, and you should rename the appropriate version to "JamTool", and place it in the same directory as the other binaries. If you will not be using a Fidonet style nodelist, pick either one, and rename it to JamTool and place it in your Path. If you do not have either a Traplist or an Igen nodelist compiled and running on your system, archives for both nodelist formats are on my system that you can Freq. Traplist.lha gives you the needed Traplist.library library and nodelist compiler. Igen1a34.lzh gives you the Igen/ Nodelist.library archive. If you are at all speed conscious, you will likely want to make JamTool resident, as that will speed things up during Fidonet handshaking. The file s:setup will likely need to be modified to setup your main log file and log window, and the long distance phone log. Currently, the main log file is logs:jammail.log, and the current long distance phone log is logs:Phone.log. The main log window is also specified in this file. Currently it is "RAW:717/13/708/206/JamMail Log Window/inactive'". This window likely will not fit on your screen. You will want to adjust its location on your screen. If you wish to put this log on a public screen, just specify the /SCREEN option in the window name. This file will eventually be generated by JamMail as well, so you will not need to configure it manually. The S:Setup file should have its execute bit set so you can launch JamMail simply by typing "SETUP" from any CLI/Shell on your system. The S:Setup script aborts JamMail if it is already running, and launches it again. It will also setup LogProc if it isn't already running on your system. If you make changes with the JamMail program, and generate a new JamMail.wpl file, simply type "Setup" and it will launch the new one. You should also set the execute bit on the CALL script, as you can use it to manually dial a system. It sends call commands to the scheduler, so the multi-line features of the system will be used as well. In your outbound directory, you will want to make a sub-directory called "Xferq", and you must make an assign to this directory in your Startup-sequence or User-startup file. Xferq.Library will store its outbound queue files in this directory. You should not touch any of the files that will be in this directory yourself. If you do not already have one, you will likely want to assign LOGS: to a directory where you store all your logs. This isn't a requirement but the defaults all use Logs: and I find it handy. 3. The JamMail Menu System. From the Main JamMail menu, you will notice a few bits of information. The Menu shows you if you have some of the more normal config options turned on or not: Fidonet, UUCP, Atomic Clock or the Scheduler. It also shows approximately what versions of WPL.library and JamTool should be used with this version of the JamMail binary. a. Configuring the FidoNet options. 1. System Address: This is your primary system address that will show up in Fidonet Sessions. 2. Inbound Name: This is the system name that will show up on the remote systems end when they call you. 3. Outbound Name: This is the system name that will show up on the remote systems end when you call out. 4. Sysop: This is your name. It will show up in the remote systems logs. 5. Inbound Directory: This is the directory that files received during a Fidonet session will go to. 6. Outbound Directory: This is the directory that outbound FileRequest files will be searched for. Typically, outbound mail will also be in this directory, but that is not required. Other Options. 1. Handshakes: Fidonet offers a couple methods of saying "Hello" with the other end to find out who each other is, and what file transfer protocols you support. Currently, I only support two methods of handshaking: FTS1 and WaZoo. EMSI will be added in a future version. 2. Outbound Pickup: This says whether or not you're willing to pickup any files during an outbound session. Make sure this option is always set to true if you call someone to pickup your mail. 3. File Requests: This says whether you will accept inbound file requests. If you set this to true, you must configure a file request server in the XferqSH menus. 4. Post Session: This command is run at the end of every Fidonet session. 5. Pre Session: This command is run before every outbound Fidonet Session. Fidonet AKA's. Because of the growing number of Alternate Fidonet networks, and the use of Multiple addresses, a number of options can be changed based on who the remote system is. A standard **AmigaDos pattern** match is done on the **remote systems** address. Address: Your new system address Inbound name: Your new system's name on inbound calls Outbound Name: Your new system's name on outbound calls Inbound directory: The new inbound directory. Outbound directory: The Directory that .REQ files are searched for. Pre Session: A custom command run before each outbound session Post Session: A command run after each session. Handshakes: You can specify which handshakes are available with this system, or group of systems. A blank entry means that you do not wish to change it from the default. Note: The # symbol is part of the AmigaDos pattern match system, so you can not match an address such as "Fidonet#1:163/139.0". You need to replace the # symbol with a ? such as "Fidonet?1:163/139.0". b. Configure UUCP options. 1. UUCICO: This is the full path name to the UUCICO binary. (this is part of the UUCP package). 2. UUCICO Opts: These are command line options that will be used when UUCICO is launched for inbound and outbound UUCP sessions. 3. Post Session: This command will be run after each UUCP session 4. Pre Session: This command will be run before each outbound UUCP session. To support UUCP/UseNet, you must setup a uucp package seperately of JamMail. JamMail will only take care of the mail transfers by launching UUCICO. Mail must be handled by other packages. I am currently using the UUCICO binary that was included in the AmigaUUCP1.15 distribution. As far as I know, the 1.16 version included in the AmigaUUCP package does not work. There is a patched version of UUCICO for WPL available on many WPL support sites as well. I also belive that the latest UUCICO distributed by Michael Smith has the required fixes to run, but I've not tested it myself. c. Configure Atomic Clock settings. Through the use of the XprClock.library file, your system clock can be set by calling one of the Atomic clock systems. 1. Post NRC: This command will be run after a successfull session. 2. GMT offset: This is the time difference between your time zone and GMT. The Default is -4 which is for EST. 3. Current Year: This is the number used when calculating the correct date. You will want to change this each January 1st. Most Atomic clock systems are using a 300bps carrier, so you have to connect to the system at 300bps. BELL103 is the mode that I use when connecting with my ZyXEL. To configure your system to be able to call an Atomic clock system, you must add an entry to your phonebook (using JTPhone), using the type NRC. This allows you to list different Atomic clock systems if you ever want to dial more than one. You should put the number 300 in the flags field, and then configure a custom dial string for each modem that you might be dialing with, to force the modem to 300bps (if it is unable to do so itself). d. Other Configs. In this menu, you can configure the system for two more session types. TERM and FAX. TERM calls are only available for outbound calls. This allows you to launch a terminal program once it connects to that system. This function is here so you can auto dial a busy BBS, but still have your own system up and running between dials. Outbound FAX support has not really been worked on, but inbound FAX's should work. 1. TERM launching: This enables or disables TERM sessions. 2. Term Command: This is the command that will be run when connected. 3. Post Term: This is the command that will be run after a TERM call. 4. Fax Launching: This enables or disables FAX sessions. 5. Inbound Fax: This is the command that will be run when a FAX response is received (see modem response configs section for more info). 6. Outbound Fax: This is the command that will be run when a connect is received on an outbound FAX call (not supported currently). 7. Post Fax: This is the command that will be run after each FAX session. Note: The Terminal program that you launch, must not launch itself from the task that launched it. Old versions of NComm removed itself from the CLI, which caused problems with launching it this way. The new NComm 3.0 (and up) launches perfectly fine from here, but since you can't specify command line arguments with the port information, you will want to make sure you only do term type dials on the modem/serial port that you have NComm configured for. The new Terminus is also supposed to be launchable at this point. I am now currently running VLT as my terminal program. If you also wish to run VLT, you must go to the "Change Misc Options menu", and click on "Do Not use OwnDevUnit", and "Open Device in Shared Mode". e. Configure Lines/Modems Section. f. Login Menu These options all deal with the "menu" system that will be provided to a user that calls into your system. If you have disabled the answer code (ie, you will not be receiving any inbound calls), this section will be completely disabled. 1. Prompt Timeout: This is the user inactivity timeout. After an inbound caller has been sitting at the prompt for this number of seconds, they will be hung up on. 2. User Prompt: This is the main prompt that will be displayed on inbound calls. If you support UUCP logins, the last word should end with ogin: as that is most commonly the pattern searched for in Dial-expect strings for UUCICO. 3. Privacy Checks: For systems supporting CallerID (Ident-a-call), this option configures what JamMail will do if a caller has blocked their number when they called you. A ZyXEL modem returns the message "Reason for no caller number: Privacy", so I scan for the pattern "#?privacy#?", and if this is found, you can do a number of things: a) Nothing b) Display a message to the user saying that they have been identified as a CID blocked user. The system will also display files before the user attemps to do file requests, or launching a BBS, and JamMail will not allow them to do either, but it will return them to the main login menu. c) Send the warning messages, but hangup after the warning message sent when the user tries to log into your BBS. d) Send the warning messages, but hangup after the warning message sent when the user tries to do a file request. e) Send the warning messages, but hangup after the user tries to do either a file request, or to launch a BBS. 4. User Freqs: You can allow users to do file requests from your front end. The user enters each file they want one per line, and enters a blank line when they are done. What is actually being done, is a .REQ file is being created in the T: directory, and once the user is done entering filenames, your "User Freq server" is launched, using this file as the request list. A Batch Zmodem transfer is then started. This feature is quite usefull if you wish to allow Long distance users to get files from your system without having to log into a BBS (or maybe you aren't running a BBS at all), but it does also allow people to be file leeches. 5. User Address: This is the address that will show up in the UserFreq Log when users are doing file requests from your system. This address doesn't really mean anything but someone may wish to use it somehow. Most File request servers do need a Fidonet address as the source of the Request list, so an address should be put here if you intend to support User File requests. 6. Menu Files: As an addition to User Freq's, up to 9 files can be downloaded directly from this menu. For each entry, a pattern can be entered, that is matched against what the user types to see if they want this file (so don't use "#?" as a pattern for one of the files, as everything a user enters will match, and they'll constantly be receiving this file). The full filename of the file to be sent, and a short message to be transfered to the user before sending this file are to be configured as well. g. Bulletin Board Launching. h. Server Text Files. i. XferqSH and other File request servers. File requests can be handled primarily through two different methods. i) a Non-Xferq aware file request handler through XferqSH. ii) an Xferq aware file request handler Most file request servers are going to fall under category i). To use one of these file request servers, Russell McOrmond has written a program called XferqSH which makes this procedure much easier. The default command lines in menu A) all use XferqSH to do the dirty work. To use XferqSH for handing file requests the following variables must be configured: XferqSH: This is the full path name to where you have placed the XferqSH program. FreqCfg: This is the full path name to the XferqSH config file you are using for file requests. LogCfg: This is the log file which will display everything that happened while executing the FreqCfg file. If you have setup the User Freq option in Menu 6) and you are using XferqSH to handle your file requests, you also need to setup the following two variables: UserFreqCfg: This is the full path name to the XferqSH config file that you are using for User File requests. UserFreqLog: This is the log file which will display everything that happened while executing the UserFreqCfg file. Note: The UserFreqCfg and FreqCfg files can be the same config file if you wish to support them the same way. A third option also exists in that you can have XferqSH do some funky things with files that come in through a regular Fidonet session. You can move specific files to other directorys (eg. Compile your nodediff before your tic processor moves it to your file area). To support this option, the following two variables must be setup and configured correctly: InboundCfg: This is the full path name to the XferqSH config file that you are using for Inbound files. InboundLog: This is the log file which will display everything that happened while executing the InboundCfg file. The Format of an XferqSH config file to support file requests or User file file requests using the internal Freq Server. ---- ; Pattern Command #? #fido:freqlist.lst fido:badfile.txt ---- A config such as this one listed, could be used for either/both of the file request configs. This specific config uses the XferqSH internal file request server. It is not particularly usefull, but if you are really lazy and don't want to setup a better file request server, this will work. The fido:freqlist.lst file is simply a text file formatted: ---- ; Name FullPath Files files:jamfiles.lha AllFiles files:jamfiles.lha ---- This possible XferqSH.cfg file would send the user my files list if they did a file request of either "Files" or "Allfiles". Everything in this file is case insensative, so it does not matter if they requested "FILES" or "FiLeS" they would still get it. If you wish the person to get two files, then you may list both files with the same name in the first column. ---- files files:jamfiles.lha files files:jamfiles.lha.readme ---- This would send both my files list, and a .readme file (if it exists). If you require the use of a Password, putting the ! and a password at the end of the entry is how you would do it. ---- files files:jamfiles.lha ! secret newfiles files:jamnewfiles.lha ! boogie ---- Using XferqSH to launch other File Request Servers & other programs. All current file request servers should work fine with JamMail. Some of them will also be able to be run asynchronously with your mailer, allowing you to do other things while it searches for the files requested (like receive more files, or start sending files). The following variables are available to be used in XferqSH.cfg files: %r - This is the filename of the file that just came in. %R - This is the full path filename of the file that just came in. %a - A full 5-d address of the remote system (eg. Fidonet#1:163/109.0) %z - Zone number of remote system. %N - Net number of remote system. %n - Node number of remote system. %p - Point number of remote system. %s - The string that was in the 5th argument of the XferqSH command line. %o - Asynchronous outbound ".rlo" file. If the file request server that you wish to run is able to be launched asynchronously, you should use this for the output file, and you should run the command. %O - Temporary ".rlo" file. If the file request server you wish to run is not able to be run asynchronously, you should use this for the output filename, and should not run the command. The XferqSh.cfg file that you use for file requests should only have one line in it (unless you are using the same XferqSH.cfg file for one or both of the other XferqSH command lines). This line, should be in the form "Pattern Command". The pattern that you want to use for your file request handler, is "#?.req", which means this line will be executed on any file that ends in .req. This allows you to support multiple .req files sent to you in the same session, as well as non-standard filenames like "1.163.139.0.req" if someone doesn't translate a 4d filename before sending it to you. If your request server requires something like. freq infile outfile 4d-address sysop baud Then your XferqSH.cfg line would be. #?.req run freq %R %o %z:%N/%n.%p %s And in the command line where XferqSH is run (menu A), you would replace the last option on the command line (the text string), with: "$(sysop) $(baud)". The 5th option (the last option), is always sent when a %s is used in an XferqSH command line. This command line above assumes that the program "Freq" can handle being run asynchronously. If it can't, the command line must change to: #?.req freq %R %O %z:%N/%n.%p %s The difference is that the command is not "RUN", and that the output filename is the capital %O instead of the little %o. It is possible, that your File request server will require a really strange group of options, and that you will need to have all of the command line options created in that last text string on the XferqSH command line, and your XferqSH.cfg file looks like this: #?.req run freq %s which would take all of the options from the 5th string that was sent on the command line when you ran XferqSH. For the Inbound.cfg XferqSH.cfg file, you can use this pattern match feature, and move specific files to other directories, or whatever you can think of. j. Logs & Window options. k. Scheduler Configs. l. Long Distance Phone Call options. m. Using JTPhone for setting up and using a phone book. JTPhone (JamTool Phone) is a little program I wrote to easily edit the phone book used by JamTool. Entries should be added to this list for any system you wish to dial that is not in the Fidonet nodelist (and likely, you'll want to add the Fidonet systems that you connect to regularly as well, since its a fast way of doing password lookups). The file JamTool.Doc has more documentation on JamTool and JTPhone if you wish to know more. The phone book format is documented in that file. 4. What's necessary for a Point/End User to configure? 5. What's necessary for a full Node to configure? 6. Using a Cron with JamMail. There are many Cron programs available for the Amiga. A very powerful Cron is called "CyberCron". It has many features, and it also uses LogProc for its logfiles. I myself use TPTCron because I have very simple needs, and I already had it setup on my system, as I previously was running a DLG BBS system. There is one specific thing related to JamMail, that does require a Cron program. This is only relevent to Nodes, so a simple point system doesn't need to run a Cron, unless they wish to automate calls to their boss/host or something like that. There is an ENV: variable that Jammail uses called "ZMH". If it is set to "TRUE" or "1", Zone Mail Hour mode will be in effect. This will dissallow any users to log into your BBS, download files from your main menu, and it will disable File requests from users, or from other Fidonet systems. If this variable is "False" or 0 (or really, anything thats not true) the system will function normally, as if the variable wasn't even there. 7. Distribution. There are a number of ways to get updates to JamMail. The absolute easiest way to do it, is to dial my system up directly and to do a file request (either using a terminal program, or a Mailer such as JamMail itself). Roger Clark @ Fidonet#1:382/105 in Austin, TX has agreed to post JamMail into the ADSFIDO file echo area in the Amiga Distribution System network. We haven't discussed how often this will be done, but this is being worked on. Internet Email. I have an Email account at the local Freenet, and can uuencode an archive up and send it to people if they ask really nicely (the reason you've got to ask nicely, is that i've got to upload the file to the freenet at 2400bps, and its not that fun :-) WPL support FTP directory on ccs.carleton.ca. There is a public WPL directory on this system, but as of yet, I have not had the chance to send any versions of JamMail to this system. I do not have direct access to it myself, and haven't sent a version to anyone that does.